1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, this invention relates to a system and method for non-synchronous access to a software component instance pool.
2. Description of the Related Art
With the advent of software components, developing distributed enterprise software applications has become simpler. Software components are portions of pre-written software code that can be used and reused by the software developer. Thus, software components allow software developers to concentrate on the more custom aspects of their program while the more tedious tasks of the program are done for them via components. For example, in the Java programming environment, enterprise java beans work as software components.
There are three types of enterprise java beans: session, message-driven, and entity beans. Session beans typically execute a single task for a single client during a session. Message-driven beans also typically execute a single task for a single client where the task is processing messages sent to or from another bean, an application client, or others. An entity bean is a persistent object which represents data (for example, customers, products, orders, and etc.) stored within a database.
“Pooling” (sharing) objects in a distributed enterprise application will decrease the amount of computer resources required to perform a task. For example, execution time and memory generally decrease when pooling is implemented. There may be multiple pools in a distributed enterprise software application. For example, the Java 2 Enterprise Edition (“J2EE”) engine uses many different object pools. There are pools for application threads, large data arrays, enterprise java beans (“EJB”), and others.
An application thread is a part of a computer program that can run independently and concurrently with other parts of the computer program. In a complex distributed software application, there may be several threads running independently or concurrently with other threads.
FIG. 1 is a prior art implementation illustrating threads accessing software component instances in a distributed enterprise software application. Threads 101_1, 101_2, . . . , 101_N are in thread pool 110. The threads in thread pool 110 share software component pool 114. A thread must gain access to software component pool 114 upon a request for a software component instance. Software component instances 103_1, 103_2, . . . ,103_P are arranged in software component instance stack 112 within software component pool 114. A thread from thread pool 110 will “pop” (remove) a software component instance from software component instance stack 112 upon request and will “push” (return) the software component instance back onto the software component instance stack 112 when the thread is finished with the instance.
Pooling software components comes at a cost, however. Access to software component pool 114 is synchronized because it is shared between threads 101_1, 101_2, . . . , 101_N. Synchronization is a scheme where only one thread has access to an object (in this case software component instance stack 112) at any given time. Popping or pushing software component instances from software component instance stack 112 will cause other threads to wait until the popping or pushing action is complete before they can access the pool. Distributed enterprise software applications can be quite complex; consequently it is not unusual to have several threads waiting for a single thread to finish popping or pushing software component instances from software component instance stack 112. This waiting time increases the time necessary for threads to complete their actions.
In a distributed enterprise software application this synchronization can act as a bottleneck. For example, this bottleneck is apparent in a J2EE application during times of heavy load (where many threads are accessing software component pool 114). A thread, upon a request for a software component from software component pool 114, will be required to wait until other threads have finished accessing software component pool 114. If the request is for a session bean or a message-driven bean, where each bean instance is used to process a single request and generally requires very short execution times, a thread may spend more time waiting to access a session bean or message-driven bean than it would spend using the session bean or message-driven bean.